Software applications which contain vulnerabilities can lead to security or compliance breaches. If this occurs, the business of the organization running the application is endangered through loss of critical/protected data, loss of reputation, loss of business, lawsuits, etc. Therefore, it is industry best practice today to apply dedicated tools for analyzing the software to effectively mitigate these risks.
A standard method for looking for security defects is Static Code Analysis (SCA). There are SCA tools for most programming languages available. However, there is currently no SCA tool for finding security and compliance issues in SAP® ABAP™ applications. This is critical for many reasons. Most (>90%) of SAP® applications are written in ABAP™, SAP®'s own proprietary programming language, and SAP® applications often process the key assets of an organization, such as personal data, production data (intellectual property) and financial data—often the most valuable and sensitive information of an organization. If this data is manipulated by exploiting vulnerabilities in the application, the impact is severe.
SAP® applications are increasingly connected to external computer systems and are accessible by a continuously growing user base. This means that the exposure of SAP® computer systems to external vulnerabilities has grown as well. SAP® applications are more in the focus of hackers, such that the likelihood for attacks increases.
As of today, existing SCA tools cannot:                Hook into the ABAP™ compiler, as this is a proprietary compiler developed by SAP®.        Mimic the ABAP™ compiler, as this is a proprietary compiler developed by SAP® with little information available.        Perform data flow analysis on ABAP™ for testing of security defects and compliance violations.        Identify authorization violations in connection with business operations, as other languages have no consistent/standard authentication and authorization mechanism and no pool of standard business functions and standard database tables.        Analyze defects or compliance violations in a business context, as other languages are not consistently embedded into a business application framework that would allow drawing such conclusions.        Identify access to critical business data in a database based on knowledge of critical standard database tables.        
SCA has been an established concept for many years (see, for example, [2, 3, 7]). Key characteristics of today's SCA tools based on those principles are as follows:                They are mostly hooked into the compiler framework of a target language and make use of existing compiler functionality.        Most scanners analyze the Bytecode (as opposed to the source code).        They convert language-specific code (from several languages) into a common (language independent) model/format.        They analyze data flow, control flow and perform a propagation of errors (see [1, 4, 9].        They apply security rules to the common model/format.        
There are vendors that offer SCA tools (see for example Fortify Software Inc. [see 2, 5]). However, there has been no SCA tool for SAP® ABAP™ Security and Compliance until today, since the ABAP™ language cannot be processed in the before mentioned way. The main reasons are:                ABAP™ has considerably more commands than other languages (Java, C, C++, .NET, PHP, etc.), some of them unique to ABAP™. Therefore ABAP™ doesn't fit into a common model as described above.        In contrast to most other languages, ABAP functions can return more than one value to the caller.        The ABAP™ APIs are delivered as source code together with the SAP© installation and are subject to constant changes due to continuous SAP© release updates. That is the standard functionality remains mostly the same, but the APIs change over time.        The ABAP™ commands vary depending on the release of the SAP® software.        ABAP™ is a vendor proprietary language and the compiler specification is not publicly available. As it is not possible to hook into the compilation process, an alternative approach is required.        The SAP® standard releases provide thousands of standard ABAP™ functions and reports that perform specific and complex business logic. SAP® ships business-related data in thousands of well known tables in the standard releases. In this way, ABAP™ commands and applications are tightly integrated with the SAP® framework, business logic and data (as opposed to J2EE, C/C++ applications etc.).        Database access in ABAP™ is fully integrated in the SAP® kernel. ABAP™ programs do not need use additional database-specific drivers. ABAP™ can make use of an intermediary database access layer, called Open SQL (OSQL), which is in turn SAP® proprietary. As a result, the ABAP™ language syntax has integrated commands that provide access to the database. Database commands based on Open SQL behave totally different than SQL access in other programming languages. As a result, the security risks are different, too.        SAP® computer systems provide integrated features for remote ABAP™ function calls (RFC), in order to perform ABAP™ code execution across distributed servers. The technical implementation/integration of RFC differs greatly from similar concepts in other languages.        The ABAP™ kernel has an integrated authentication and authorization mechanism. ABAP™ commands make use of this mechanism in order to check if users have sufficient authorization(s) to execute any given business logic. This results in problems unique to ABAP™ and requires specific analysis logic by a SCA tool.        There is no common knowledge on ABAP™ security (rules) in the market. The only comprehensive book on ABAP™ security testing was written by employees of Virtual Forge.        ABAP™ different programming paradigms, namely Function Modules, Reports, Programs and Forms, Classes and Methods, Dynpros, Transactions, Business Server Pages, and Web Dynpro ABAP™. Each paradigm requires special consideration by a SCA tool.        SAP® has a proprietary client (SAPGUI) to execute ABAP™ Programs, Reports, Dynpros and Transactions. This requires special consideration for data flow analysis, as SAPGUI applications process user input in a unique, SAP©-specific way. Additionally, ABAP™ commands can directly interact with a client (computer) through SAPGUI by SAP® proprietary mechanisms. This requires special consideration for testing.        SAP® provides two integrated frameworks for Web applications: Business Server Pages (BSP—since release 6.10) and Web Dynpro ABAP™ (WDA—since release 6.40). Both frameworks require special consideration for data flow analysis, as they process user input in a unique, SAP©-specific way.        The ABAP™ source code is stored in database tables, not in the file computer computer system (as is common in other languages). Additionally, the source code for each ABAP™ programming paradigm is stored in a different way and location. This requires a special mechanism to access the source code.        In some ABAP™ programming paradigms, parts of the final ABAP™ code are automatically generated by the SAP framework. This obscures the relation to the original coding and requires special attention by a SCA tool.        Authorizations, computer computer system configuration, etc. is also stored in database tables (with standard names). This opens completely new ways to calculate the business impact of technical defects in the context of the business configuration.        ABAP™ has integrated commands for debugging.        ABAP™ has an interface for calling Java applications (JCo) that is an ABAP program can call a Java program and vice versa.        
In light of these complications, the need remains for a SCA tool, apparatus and method for detecting, prioritizing and fixing security defects and compliance violations in SAP® ABAP™ code. Further details regarding the ABAP language are available in standard literature (e.g. [10]).